Journaling file systems are important to ensure file system consistency in the event of a system crash, power outage or other system disabling incident. Journaling file systems may write pending or committed but un-applied transactions to a log or journal in advance of attempting to write them to an associated file system. These committed but un-applied transactions may be committed, but not committed but not yet applied to the actual file system data and meta-data blocks on disk. Journaling file systems may allow committed but un-applied transactions to be read from a journal or log as part of a recovery process and to be written to disk. This may allow a system to ensure file system integrity in the event of a failure. Committed but un-applied transactions, however, must be read from the log or journal and written to the file system in sequential order to maintain the integrity of the file system. This causes a bottleneck in performance of system recovery in journaling file systems. The performance impact is particularly significant as the size of the file system increases and the number of committed but un-applied transactions rises. For example, in a cluster file system it may be necessary to recover all committed but un-applied transactions from a failed node in a cluster and write them to disk prior to resetting the state of distributed locks related to the failed node. This may require a cluster file system to sequentially replay all committed but un-applied transactions of a failed node from a journal or log associated with the failed node and to write these transactions to disk prior to beginning a next step in a recovery process. The delay in recovering a cluster file system may thus be significant.
In view of the foregoing, it may be understood that there are significant problems and shortcomings associated with current methods of recovering journaling file systems.